Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-043.txt

Text File | 1992-11-18 | 41.5 KB | 1,164 lines | [TEXT/MPS ]

C.S.M.P. Digest             Tue, 07 Apr 92       Volume 1 : Issue 43

Today's Topics:

    Copybits ATE my colors!
     MPW Shell 3.2.2
    C++ code : Translation of MacApp sample program Calc
    MPW C package missing files?
    (Q) Mixing PlaySnd and MacInTalk
    Graf3D
    Prototyper v.3.0
    Zoom Rect. Code Needed
    Question on allocating memory for array??
    Writing a WDEF that uses the default WDEF?
    Random Numbers (Toolbox Built-in)


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Thomas Busey)
Subject: Copybits ATE my colors!
Organization: University of Washington
Date: Thu, 27 Feb 1992 18:20:56 GMT

We are using offscreen gworlds to do offscreen pixmaps.  We are
fairly sure we are setting up the gworlds properly, setting bit 14,
setting the palette colors to explicit and animated, and setting
up the cluts properly.

As a test, we tried to copybits the main screen ONTO ITSELF:

copyBits(myWindow^.portBits, myWindow^.portBits,
                     destRect, destRect, srcCopy, NIL);

This had the net effect of changing all of the nice, pretty colors on the
screen into either the foreground or background colors.

What are we doing wrong?  Do we need to handle inverse tables somehow?

Eventually we want the ability to copy the offscreen image onto the screen,
but do this in such a way that the current clut is all background colors.
Then we can switch in the foreground clut and make the image appear all at once.

Is this possible?  Why isn't our copybits working properly?

Thanks,

Tom Busey
University of Washington
Seattle, WA
[e-mail]




- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Date: 5 Mar 92 16:07:09 GMT
Organization: MacDTS, Apple Computer

In article <busey.699214856@milton>, [e-mail] (Thomas Busey) writes:
>
> We are using offscreen gworlds to do offscreen pixmaps.  We are
> fairly sure we are setting up the gworlds properly, setting bit 14,
> setting the palette colors to explicit and animated, and setting
> up the cluts properly.
>
> As a test, we tried to copybits the main screen ONTO ITSELF:
>
> copyBits(myWindow^.portBits, myWindow^.portBits,
>                      destRect, destRect, srcCopy, NIL);
>
> This had the net effect of changing all of the nice, pretty colors on the
> screen into either the foreground or background colors.
>
> What are we doing wrong?  Do we need to handle inverse tables somehow?
>
> Eventually we want the ability to copy the offscreen image onto the screen,
> but do this in such a way that the current clut is all background colors.
> Then we can switch in the foreground clut and make the image appear all at once.
>
> Is this possible?  Why isn't our copybits working properly?

You're copying from a GDevice (the main screen) that doesn't have bit 14 set.
Therefore, QuickDraw will attempt to do plain old color matching for the colors.
However, you've used most of the colors as animating colors, and QuickDraw won't
use those entries to match the colors it wants, so everything ends up mapping
to a limited set of colors (usually black and white).  It sounds like you're
doing everything right so far; CopyBits is working properly.  If you were to
copy from the offscreen, everything would work fine, because it has bit 14 set,
so it will do palette mapping.

Tim Dierks
MacDTS, but I speak for myself

---------------------------

From: [e-mail] (Jess M Holle)
Subject:  MPW Shell 3.2.2
Date: 27 Feb 92 19:06:29 GMT
Organization: Purdue University Engineering Computer Network

I've posted this once with no response, so I'm trying again.

I recently noticed MPW Shell 3.2.2 on ftp.apple.com.  I own MPW 3.2,
so I would like to know what are the differences between MPW Shell
3.2 and 3.2.2 (i.e. bug fixes, new features, etc).

Thanks to any and all who reply.

Jess Holle



- -------------------------

From: [e-mail] (Kent Sandvik)
Date: 6 Mar 92 16:54:13 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (Joe Francis) writes:
>
> In article <[e-mail]>
> [e-mail] (Jess M Holle) writes:
>
> > I recently noticed MPW Shell 3.2.2 on ftp.apple.com.  I own MPW 3.2,
> > so I would like to know what are the differences between MPW Shell
> > 3.2 and 3.2.2 (i.e. bug fixes, new features, etc).

> Here is my NON_APPLE_EMPLOYEE TOTAL GUESS (tm).  ETO #6 had a botched
> MPW 3.2.1 shell on it.  My guess is 3.2.2 is a correction that has been
> placed on ftp.apple.com to enable us ETO hosers to get the 3.2.1
> functionality without the 3.2.1 disfunctionality.  I just use the
> experimental Shell - I've never had more than cosmetic bugs with them
> and I use the new features (in fact, I pretty much find things like
> "ObsoleteProjectFile" neccessary for sanity preservation).

This is more than a guess :-). MPW 3.2.1 had a problem in combination with
Projector. If you are bitten by this combination, roll back to MPW 3.2, or
download 3.2.2 from AppleLink or ftp.apple.com. Or wait for ETO#7 which
should be out within two weeks.

Cheers,
Kent

- --
Kent Sandvik - Apple DTS  - Dynamic Language Evangelist
[e-mail]
All opinions expressed are my own, and not related to any company or
organization.           Have fun!

---------------------------

From: [e-mail] (Pavithran D Thomas)
Subject: C++ code : Translation of MacApp sample program Calc
Organization: The Ohio State University
Date: Thu, 27 Feb 1992 23:26:06 GMT

I'm a graduate student with fair-to-extensive programming experience on
the Mac.  However, I'm just beginning to work with MacApp and C++.  I
need to implement a simple spreadsheet within a larger application which
I am writing in C++.  I went through the sample spreadsheet code (Calc) which
comes as an example with MacApp 2.0, and realize that this would be very
helpful in my quest.  I'm wondering, however, if a version of Calc exists
in C++, and if so, would a kind soul with knowledge of such a creature
help me obtain a copy that I could learn and adapt from?

Thanks!

-pavi-
_____________________________________________________________________________
Pavithran D. Thomas                            [e-mail]
Graduate Student / Systems Programmer       [e-mail]
        Dept. of Mechanical Engineering, The Ohio State University


--
_____________________________________________________________________________
Pavithran D. Thomas                                       [e-mail]
Graduate Student / Systems Programmer       [e-mail]
        Dept. of Mechanical Engineering, The Ohio State University



- -------------------------

From: [e-mail] (Kent Sandvik)
Date: 5 Mar 92 20:36:29 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Pavithran D Thomas) writes:
>
> I'm a graduate student with fair-to-extensive programming experience on
> the Mac.  However, I'm just beginning to work with MacApp and C++.  I
> need to implement a simple spreadsheet within a larger application which
> I am writing in C++.  I went through the sample spreadsheet code (Calc) which
> comes as an example with MacApp 2.0, and realize that this would be very
> helpful in my quest.  I'm wondering, however, if a version of Calc exists
> in C++, and if so, would a kind soul with knowledge of such a creature
> help me obtain a copy that I could learn and adapt from?

MacApp 3.0 has Calc rewritten in C++ - so yuo don't need to do the job.

Cheers,
Kent Sandvik/DTS

---------------------------

From: [e-mail] (Bruce Young)
Subject: MPW C package missing files?
Date: 27 Feb 92 23:28:41 GMT

I am posting this question for a friend who doesn't have
access to news. If it has been discussed, I apologize, but
I don't normally read comp.sys.mac.programmer. Here is
his question:
    I recently purchased the MPW C v3.2 compiler, and
the new system toolbox and interfaces was missing the files
CInterface.O and CRuntime.O, which the manual says should
be there. Without these files, I cannot successfully link a
C application because the compiler expects them to be there.
I have talked to APDA and have been unsuccessful in finding
anyone with a technical background. They have been completely
unsympathetic, and offer no solution or explanation to the
missing files problem. Does anyone what is going on with this?

If anyone knows the name of someone at apple or APDA who could
get these files to Scott, or whether the package can be made
to work without them, or even if someone could email the files
to me, so I could download them and pass them on, it would be
greatly appreciated.

Thanks,
Bruce

[e-mail]



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  MPW C package missing files?
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: 28 Feb 92 09:55:16

In article <[e-mail]> [e-mail] (Bruce Young) writes:
>I am posting this question for a friend who doesn't have
>access to news. If it has been discussed, I apologize, but
>I don't normally read comp.sys.mac.programmer. Here is
>his question:
>    I recently purchased the MPW C v3.2 compiler, and
>the new system toolbox and interfaces was missing the files
>CInterface.O and CRuntime.O, which the manual says should
>be there. Without these files, I cannot successfully link a
>C application because the compiler expects them to be there.

Actually, the *Linker* expects them to be there, since the *Makefile* told him
so, and the Makefile is wrong :-). Beginning with MPW 3.2, these two files are
not needed anymore (In fact it is harmful to take old versions and link them
in. So, just remove the two files and link with Interface.o and Runtime.o
instead.

>I have talked to APDA and have been unsuccessful in finding
>anyone with a technical background.

Grrrrrrrrrrrr. Can I quote you on that ?

Matthias

- ---
Matthias Neeracher                                   [e-mail]
 "I have talked to APDA and have been unsuccessful in finding
  anyone with a technical background." -- Bruce Young



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Date: 3 Mar 92 23:29:23 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Bruce Young) writes:
>     I recently purchased the MPW C v3.2 compiler, and
> the new system toolbox and interfaces was missing the files
> CInterface.O and CRuntime.O, which the manual says should
> be there. Without these files, I cannot successfully link a
> C application because the compiler expects them to be there.
> I have talked to APDA and have been unsuccessful in finding
> anyone with a technical background. They have been completely
> unsympathetic, and offer no solution or explanation to the
> missing files problem. Does anyone what is going on with this?

If you'll examine the release notes, you'll find that CRuntime.o and
CInterface.o have been removed from the 3.2 release; all their routines
are now contained within Runtime.o and Interface.o.  Edit your make files
to use the generic libraries:

change all occurances of {CLibraries}CRuntime.o   to {Libraries}Runtime.o
   "    "      "       " {CLibraries}CInterface.o to {Libraries}Interface.o

then delete any duplicates on your link line (specifically, you'll probably
now have two references to Interface.o).

Enjoy,
Tim Dierks
MacDTS, but I speak for myself

---------------------------

From: [e-mail] (Gary Sager)
Subject: (Q) Mixing PlaySnd and MacInTalk
Date: 28 Feb 92 16:37:20 GMT
Organization: Sun Microsystems


I have a program that works fine doing just PlaySnd, or just MacInTalk, but if I
mix the two, the program bombs (have to power off the machine!) apparently some-
where in PlaySnd.  This is true even if it has been some time since the last call
to MacInTalk, and if I have called SoundOff to shut off the MacInTalk driver.
I have looked at all the related pointers and data at initialization and at call
time, and nothing seems to be getting scrambled.

This is on a IIsi.

Does anyone have a clue why this might be happening (beyond the ever-possible
obscure bug I might have)?  I have heard that there is some problem with sound
on the IIsi, where sound gets disabled, but this seems much more extreme.



- -------------------------

From: [e-mail] (Owen M. Hartnett)
Subject:  (A) Mixing PlaySnd and MacInTalk
Date: 1 Mar 92 06:53:33 GMT
Organization: Brown University Department of Computer Science

In article <[e-mail]> [e-mail] writes:
>
>I have a program that works fine doing just PlaySnd, or just MacInTalk, but if I
>mix the two, the program bombs (have to power off the machine!) apparently some-
>where in PlaySnd.  This is true even if it has been some time since the last call
>to MacInTalk, and if I have called SoundOff to shut off the MacInTalk driver.
>I have looked at all the related pointers and data at initialization and at call
>time, and nothing seems to be getting scrambled.

Try closing the sound driver, then opening it again, when you switch modes.
Use the CloseDriver, OpenDriver calls, Inside Mac II-178 or so.  Inside Mac
says you probably will never have to close the sound driver, but this time
you do!

Remember that Macintalk is using the old sound driver, not the new one, so
you'll have to use the old calls to close it.

-Owen

Owen Hartnett                [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
        without knowledge, of things without parallel."
            -Ambrose Bierce - The Devil's Dictionary



- -------------------------

From: [e-mail] (Donald T. Major)
Subject:  (Q) Mixing PlaySnd and MacInTalk
Organization: SAS Institute Inc.
Date: Mon, 2 Mar 1992 19:30:23 GMT

In article <[e-mail]>, [e-mail] (Gary Sager) writes:
|>
|> I have a program that works fine doing just PlaySnd, or just MacInTalk, but if I
|> mix the two, the program bombs (have to power off the machine!) apparently some-
|> where in PlaySnd.  This is true even if it has been some time since the last call
|> to MacInTalk, and if I have called SoundOff to shut off the MacInTalk driver.
|> I have looked at all the related pointers and data at initialization and at call
|> time, and nothing seems to be getting scrambled.
|>
|> This is on a IIsi.
|>
|> Does anyone have a clue why this might be happening (beyond the ever-possible
|> obscure bug I might have)?  I have heard that there is some problem with sound
|> on the IIsi, where sound gets disabled, but this seems much more extreme.

The reason is because PlaySnd is a Sound Manager routine (and therefore
compatible with it) while MacinTalk is a pre-Sound Manager system
extension, for which Apple has only the code, not the source, and which
is NOT Sound Manager compatible.  You can't mix and match the two,
because while Apple managed to make the system support pre-Sound Manager
code, they did so at the expense of using the Sound Manager thereafter,
or such is my understanding.  At any rate, it's not really a bug, but
a failure on your part to pay attention to Apple's disclaimer about
MacinTalk--use at your own risk.

                                             ..
                                            dtm

--
Donald Major       SAS Institute Inc.  "Cicely, let's fling something!"
[e-mail] SAS Campus Drive                 - Northern Exposure
[phone]     Cary, NC 27513-2414



- -------------------------

From: [e-mail] (Chris Wysocki)
Subject:  (A) Mixing PlaySnd and MacInTalk
Date: 2 Mar 92 23:12:36 GMT
Organization: Harvard University, Cambridge, MA

In article <[e-mail]>, [e-mail] (Owen M.
Hartnett) writes:

> In article <[e-mail]> [e-mail] writes:
>
> >I have a program that works fine doing just PlaySnd, or just MacInTalk, but if I
> >mix the two, the program bombs (have to power off the machine!) apparently some-
> >where in PlaySnd.  This is true even if it has been some time since the last call
> >to MacInTalk, and if I have called SoundOff to shut off the MacInTalk driver.
> >I have looked at all the related pointers and data at initialization and at call
> >time, and nothing seems to be getting scrambled.
>
> Try closing the sound driver, then opening it again, when you switch modes.
> Use the CloseDriver, OpenDriver calls, Inside Mac II-178 or so.  Inside Mac
> says you probably will never have to close the sound driver, but this time
> you do!
>
> Remember that Macintalk is using the old sound driver, not the new one, so
> you'll have to use the old calls to close it.

Actually, MacinTalk doesn't use any of the OS sound routines; instead, it
writes directly to the sound hardware addresses of the original Macintosh.
The only reason that MacinTalk still works with more recent Mac models is
that the Sound Manager goes into a so-called "compatibility mode" when it
senses activity at the old sound hardware addresses.  The Sound Manager
normally turns off "compatibility mode" only at _ExitToShell; however, if
you reset the appropriate bit in register B of the VIA chip, you can reset
"compatibility mode" yourself, thereby allowing you to combine MacinTalk
with Sound Manager calls.  The two necessary lines of assembly code are:

        MOVEA.L VIA,A0          ; get address of VIA register B
        BSET    #vSndEnb,(A0)   ; turn off sound

After doing this, you should wait at least 60 ticks for the "sound sniffer"
VBL task to notice the change; failure to do this will likely result in
unpredictable system crashes.

Chris Wysocki
[e-mail]



- -------------------------

From: [e-mail] (Michael Kohne)
Subject:  (Q) Mixing PlaySnd and MacInTalk
Organization: University of Maryland Baltimore Campus, Computer Science Department
Date: Tue, 3 Mar 1992 01:55:02 GMT

In article <[e-mail]> [e-mail] (Donald T. Major) writes:
>In article <[e-mail]>, [e-mail] (Gary Sager) writes:
>|>
>|> I have a program that works fine doing just PlaySnd, or just MacInTalk, but if I
>|> mix the two, the program bombs (have to power off the machine!) apparently some-
>|> where in PlaySnd.  This is true even if it has been some time since the last call
>|> to MacInTalk, and if I have called SoundOff to shut off the MacInTalk driver.
>|> I have looked at all the related pointers and data at initialization and at call
>|> time, and nothing seems to be getting scrambled.
>|>
>|> This is on a IIsi.
>|>
>|> Does anyone have a clue why this might be happening (beyond the ever-possible
>|> obscure bug I might have)?  I have heard that there is some problem with sound
>|> on the IIsi, where sound gets disabled, but this seems much more extreme.
>
Ok, who has the source to MacinTalk?




--
"Pope" Q.E.D         Lord High Jabberwocky
Michael Kohne        [e-mail]
Coded Message: FIME NDUXXMS MZP FTQ EXUFTK FAHQE SKDQ MZP SUYNXQ UZ FTQ IMNQ.



- -------------------------

From: [e-mail] (Amanda Walker)
Organization: Visix Software Inc., Reston, VA
Date: Wed, 4 Mar 92 04:49:35 GMT

[e-mail] (Michael Kohne) writes:
> Ok, who has the source to MacinTalk?

Nobody, not even Apple.  That is precisely the problem.

Amanda Walker                              [e-mail]
Visix Software Inc.                    ...!uupsi!visix.com!amanda
- --
"You're making the same mistake that I did--assuming people are capable of
 figuring out obvious behavior, when in practice they're not" --Eric Wiseblatt

---------------------------

From: [e-mail] (howard l. berkey)
Subject: Graf3D
Date: 29 Feb 92 04:54:24 GMT


Hi!
    I just got the upgrade to THINK C 5.0.2 and noticed the library
Graf3D.  I looked in the manual and couldn't find any info but by the header
it appears to be a full-featured 3D graphics library.  Is this true?  I haven't
had time to try it yet... If you have any info about it, please e-mail it to
me at:
        [e-mail]
    and I'll post any info given in a follow-up.

Thanks in advance!!!!
    -Howard



- -------------------------

From: [e-mail] (howard l. berkey)
Date: 3 Mar 92 07:08:57 GMT

Thanks to all who responded to my questions about Graf3D!
I've got about 20 pages of info now so instead of posting a follow-up,
if you're interested, email me at this addr:
    [e-mail]
and I'll get back to you.

    -Howard

---------------------------

From: [e-mail] (Kent S. Harris)
Subject: Prototyper v.3.0
Date: 28 Feb 92 17:44:23 GMT
Organization: Vine Technology, Cupertino, CA

Anyone have anything to say about Prototyper v.3.0 from Now Software, Inc.
I need to design a fancy user interface for an application.

Thanks.


--
Kent S. Harris    ...!ames!vine!ksh    CONSULTING: Real-time system h/w & s/w,
Vine Technology   ([e-mail])          software development tools, project
[phone]     22 yr EE/CS exp.        analysis, information modeling.



- -------------------------

From: [e-mail] (David Dantowitz)
Subject:  Prototyper v.3.0
Organization: UCLA Computer Science Department
Date: Sat, 29 Feb 92 22:38:18 GMT

In article <[e-mail]> [e-mail] (Kent S. Harris) writes:
>Anyone have anything to say about Prototyper v.3.0 from Now Software, Inc.
>I need to design a fancy user interface for an application.

I bought a copy and was a bit disapointed because it crashes quite
easily.  It does however do okay every time you restart your machine
or the app.  If you're just playing with menus and windows it's ok,
but if you're trying to do anything fancy (and you can program an
interface) you're better off writing your own C or Pascal, etc. code.

You may be better off with Appmaker (provided it doesn't crash very
often).  Also, last year Prototyper's developer had a disagreement
with Now Software.  I'm not sure where this lead, but I haven't seen
an upgrade or any hint of one... They also covered up his picture on
the box they sent me with a poorly glued on page.

How's that for someting to say?



--
David Dantowitz
[e-mail]

Singing Barbershop when I'm not computing...



- -------------------------

From: [e-mail] (Terry Monks)
Subject:  Prototyper v.3.0
Date: 2 Mar 92 15:07:47 GMT
Organization: Automata Design, Inc.

[e-mail] (Kent S. Harris) writes:
: Anyone have anything to say about Prototyper v.3.0 from Now Software, Inc.
: I need to design a fancy user interface for an application.

I have been using it for years, ever since the first version and
really like it. Early versions of 3.0 seems to have had a crashing
problem, but I have been using the latest heavily for a week now under
System 7 and have had no crashes at all.

If you are using it with Think C 5, you will have to take care of
a problem with include files that Symantec may have introduced in
their latest changes. However, Symantec provides an application
called "Propotyper Helper" that will process all your source files
and take care of things quite nicely. Still it *is* an extra step.

Prototyper is very good at managing a changing prototype, i.e. one
that you sketch out once, convert to code and run for a while, and
then go back to make changes to the original prototype, but merge
them with whatever *real* codes you have created in the meantime.


:
: Thanks.
:

You welcome.

--
Terry Monks        Automata Design Inc    [phone]



- -------------------------

Organization: Queen's University at Kingston
Date: Monday, 2 Mar 1992 22:47:13 EST
From: <[e-mail]>

Before you lay down your money for Prototyper take a look at AppMaker
(Bowers Development 508/369-8175).  Both perform similar functions but
differently.  I bought Prototyper some time ago, and later bought AppMaker.
I was much happier with AppMaker (which didn't destroy my code changes and
additions--I believe Prototyper now has a similar ability, but I haven't
bothered to upgrade it).  I also prefered the AppMaker interface, but that's
more a matter of personal preference.

.../dave   Dave Charlesworth

- -------------------------

From: [e-mail] (Jay H. Lieske Sr)
Organization: Jet Propulsion Laboratory
Date: Tue, 3 Mar 92 20:38:36 GMT

    I have had Prototyper since version 1 first came out, and I faithfully
'upgraded' each time a new version was issued.  I was very dissatisfied with
Version 3 and consider it a rather sloppy beta issue.  It won't even generate
Pascal code that can successfully be compiled for any of the sample Pascal
programs that are included with the program.  Now Software (SmethersBarnes)
told me they'd send me an update when everything worked.  That was more than 16
months ago and I haven't received anything from them.
    I understand that the author of Prototyper (George Cossey) tried to have it
withdrawn because it was not ready for distribution.  I believe that currently
there's a law suit going on between the original author and Now Software.  The
original author now produces an alternative product called Marksman.


Jay H. Lieske Sr
[e-mail]


- -------------------------

From: [e-mail] (Carl W. Haynes III)
Date: 3 Mar 92 23:10:37 GMT
Organization: Purdue University Computing Center

In article <[e-mail]> [e-mail] (Jay H. Lieske Sr) writes:
>
>    I understand that the author of Prototyper (George Cossey) tried to have it
>withdrawn because it was not ready for distribution.  I believe that currently
>there's a law suit going on between the original author and Now Software.  The
>original author now produces an alternative product called Marksman.

I received my copy of Marksman about a month ago, I had previously owned
Prototyper 2.0 and 3.0. Here's my take on Marksman:

As other people have mentioned, Prototyper 3.0 was riddled with bugs,
it really was like a real early beta copy. Marksman fixes most of the
bugs and is usable, but it still feels like a beta release, there are
many problems which are so obvious, it seems like it was not tested
thoroughly before release.

Some of the problems I've had with it are: crashes when I select the pattern
box in the 'hot spot' dialog; Many of the dialogs are too big to fit
a 9" monitor (the Scroll box dialog for example). It allows you to drag
a window off the top the screen (no way to get it back). Again it feels
like no one tested it on a compact Mac.

Although not a bug, my biggest peeve with Prototyper and now Marksman,
is that it does not allow for creating multiple instances of windows.

Overall, Marksman is usable as long as you know what not to touch, unlike
Prototyper which crashed whenever it felt like it. I used Prototyper
and now Marksman for making up Mock-Ups of programs before I write
the code, it is very useful when someone else has an idea for a
program, I can sit with them and design the interface. Marksman
is a definite improvement over Prototyper for doing this.

I've never used AppMaker so I don't know how it compares.

carl
[e-mail]
AOL: CWH3

- -------------------------

From: [e-mail] (Andrew Dent)
Organization: DIALix Services, Perth, Western Australia
Date: Wed, 04 Mar 92 13:41:43 GMT

In <[e-mail]> [e-mail] (David Dantowitz) writes:

>In article <[e-mail]> [e-mail] (Kent S. Harris) writes:
>>Anyone have anything to say about Prototyper v.3.0 from Now Software, Inc.
>>I need to design a fancy user interface for an application.

>I bought a copy and was a bit disapointed because it crashes quite
>easily.  It does however do okay every time you restart your machine

>You may be better off with Appmaker (provided it doesn't crash very
>often).  Also, last year Prototyper's developer had a disagreement
>with Now Software.  I'm not sure where this lead, but I haven't seen

The new product is called MarksMan and is pretty similar to Prototyper in
operation. The rumour on CompuServer was that the disagreement came about
because the developer (George Cossey) shipped a buggy beta to Now and
they went ahead and released it as Prototyper 3.

Marksman vs AppMaker is a matter of snazzy interface - Marksman is lots
easier to use, includes good colour support (including heaps of colour
plug-in CDEFs etc.) and has all the Prototyper stuff such as menu control
etc.

I've switched to AppMaker because I need code generated for the Think
Class Library and the MarksMan code generators don't follow the class
library philosophy in a very OOP fashion (woeful DoCommand hierarchy
support and no command numbers). However, I'm finding AppMaker LOTS
harder to lay out my screens and it has virtually no colour support.
Also, AppMaker lacks the "linking" facility that lets you generate code
that automatically disables/enables things, swaps windows etc. This is
not much of a hassle if you are using it with TCL as the class library
does much of this anyway.

Both products are well supported on Compu$serve.

Andy Dent
A.D. Software - Mac, PC & Vax Programming and Training
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241
"It's amazing what one can accomplish when one doesn't know
 what one can't do" (Garfield)



>--
>David Dantowitz
>[e-mail]

>Singing Barbershop when I'm not computing...

---------------------------

Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA
Date: Sat, 29 Feb 1992 03:44:19 -0500
From: Shawn James Cokus <[e-mail]>
Subject: Zoom Rect. Code Needed


Does anybody have some zoom rectangle (like that used in the Finder)
code he/she would be willing to share?  Actually, the code isn't needed;
a description of how to generate the successive rectangles making up
each frame is all I require.  I have some ideas on how this is done, but
I suspect that there is some standard method that is consistently used.
E-mail replies are fine.  Thanks in advance,

--Shawn.


-- Shawn Cokus
--   [e-mail]
--   Carnegie-Mellon University, Pittsburgh, PA
--   (Witty phrase temporarily out of order.)




- -------------------------

From: [e-mail] (Lincoln Stein)
Organization: Massachusetts Institute of Technology
Date: Tue, 3 Mar 1992 12:28:50 GMT

>Does anybody have some zoom rectangle (like that used in the Finder)
>code he/she would be willing to share?  Actually, the code isn't needed;
>a description of how to generate the successive rectangles making up
>each frame is all I require.  I have some ideas on how this is done, but
>I suspect that there is some standard method that is consistently used.
>E-mail replies are fine.  Thanks in advance,


Here's how I did it in Pascal.  I haven't looked at this code for years,
but I use it frequently:

unit Zoom;

interface

{ZoomRect is a procedure which zooms a series of dotted rectangles from}
{startRect to endRect.  Pass it the rects in GLOBAL coordinates.}

procedure ZoomRect (startRect, EndRect: rect);

implementation

{-----------------------------------------------------------------------}
  procedure ZoomRect (startRect, EndRect: rect);
    const
      NumRects = 4; {Number of rectangles displayed at once (the latency)}
      Steps = 18;   {Coarseness of the grain}
    var
      TopStep, LeftStep, BottomStep, RightStep, i, j: integer;
      EmptyRect: rect;
      RectList: array[1..NumRects] of rect;
      aPort, oldPort: Grafptr;
      portStorage: GrafPort;
  begin
    TopStep := (EndRect.top - StartRect.top) div steps;
    LeftStep := (EndRect.left - StartRect.left) div steps;
    BottomStep := (EndRect.bottom - StartRect.bottom) div steps;
    RightStep := (EndRect.right - StartRect.right) div steps;

    GetPort(oldPort); {save the current port}

    aPort := GrafPtr(@portStorage); {make aPort point to stack storage}

{open the port and make it current -- whole screen is used}
    OpenPort(aPort);
    PenMode(notpatXor);
    PenPat(gray);

    SetRect(EmptyRect, 0, 0, 0, 0);
    for i := 1 to NumRects do
      RectList[i] := EmptyRect;

    for i := 1 to steps - 1 do
      begin
        FrameRect(RectList[1]);   {erase first rect}
        StartRect.top := StartRect.top + TopStep;
        StartRect.left := StartRect.left + LeftStep;
        StartRect.bottom := StartRect.bottom + BottomStep;
        StartRect.right := StartRect.right + RightStep;
        FrameRect(StartRect);   {paint next rect}
        for j := 1 to NumRects - 1 do
          RectList[j] := RectList[j + 1];
        RectList[NumRects] := StartRect;  {remember last rect}
      end;

    for i := 1 to NumRects do
      FrameRect(RectList[i]);     {final erasure}

    ClosePort(aPort); {close the temporary port}

    SetPort(oldPort); {restore the previous port}
  end;
end.

===============================================================================
Lincoln D. Stein                                Brigham & Women's Hospital
[e-mail]                           Boston, MA
===============================================================================

---------------------------

From: [e-mail] (Mengyik Yeong)
Subject: Question on allocating memory for array??
Date: Sat, 29 Feb 1992 22:05:42 GMT

I am trying to write a routine to allocate memory for an array which
can have a variable number of elements.  I actually got this routine
from A Book on C (Iforget the autho's name).  Could someone tell me why
it does not work.  It is probably something silly which I didn't see.
Here's the code:

    double **GetMatMem(short int n)
    {
        double **a;
        short int i;

        a=(double **)calloc((unsigned long)n,
                    (unsigned long)sizeof(double *));
        for (i=0;i<n;++i)
            *(a+i)=(double *)calloc((unsigned long)n,
                        (unsigned long)sizeof(double));
    }

I am using Think C 5.0.  The program hangs in the for loop (Bus Error).
Using the debugger it seems like the problem is with the *(a+i) expression,
i.e. when I type *(a+i) into the debugger window it gives me **bus error**.

Any help would be greatly appreciated.
Oh! I forgot, there is a return(a) after the for loop, but it never
reaches that point.

Thanks
Mengyik
[e-mail]




- -------------------------

From: [e-mail] (Alan Toman)
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Tue, 3 Mar 92 13:36:26 GMT


There is nothing wrong with the code, per se, however with THINK C 5.0
#include <stdlib.h> must be included for calloc (an d malloc, etc) to
work correclty.  Another option is to replace the calloc calls with
NewPtrClear.

---------------------------

From: [e-mail] (Blake Ward)
Subject: Writing a WDEF that uses the default WDEF?
Date: 1 Mar 92 18:03:21 GMT
Organization: School of Computer Science, Carnegie Mellon


I'd like to write a WDEF that adds an extra little icon (button) to the title
bar (and detects clicks in it), but otherwise behaves extactly the same as
the default system WDEF for documents.  Since I'd like to get all of the
system's WDEF behavior for free (and be compatible with any future changes),
I'd like to pass most of the messages like wCalcRgns, wGrow, etc. on to the
default WDEF unchanged.  I could pass the wDraw message to the default WDEF
and then also draw my own icon before returning.  Similarly, for the wHit
message I could check first if the mouse went down in my icon and if not,
just pass the message on to the default WDEF.

Is there anyone out there who has already done something like this and would
be willing to give me some sample code?  If not, do any of you have any
suggestions, caveats, etc.?  Thanks in advance.



- -------------------------

From: [e-mail] (Pete Gontier)
Date: Tue, 03 Mar 1992 00:35:20 -0500

 BW> From: [e-mail] (Blake Ward)

 BW> I'd like to write a WDEF that adds an extra little icon (button) to the
 BW> title bar (and detects clicks in it), but otherwise behaves extactly
 BW> the same as the default system WDEF for documents. Since I'd like to
 BW> get all of the system's WDEF behavior for free (and be compatible with
 BW> any future changes), I'd like to pass most of the messages like
 BW> wCalcRgns, wGrow, etc. on to the default WDEF unchanged.

Wait, this is a test, right? You're a _d e v e l o p_ editor in disguise
trying to see if anyone's paying attention, right?

Try this month's _d e v e l o p_, available on a CD near you (or through
snail mail), in which this topic is specifically addressed.

---------------------------

From: [e-mail] (Christopher Kempke)
Subject: Random Numbers (Toolbox Built-in)
Date: 2 Mar 92 08:12:53 GMT
Organization: Oregon State University, Computer Science Dept.


    Hope this isn't a FAQ, I've just resumed reading after a long
    absence.  I've got a couple questions for any knowledgable types
    out there.

    Regarding the builtin Random() function:

    For a given RandSeed, will this function return the SAME sequence
    of numbers over all Macintosh models?

    Is this function's implementation likely/unlikely/inconceiveably (sp!)
    going to change in the future, or can I rely on always getting the
    same sequence for a given seed?

    What is the algorithm itself, unless it's proprietary?
    (This last question is only really necessary if I can't rely
    on the builtin function to remain constant.)

    I'm doing "fractal" (actually midpoint subdivision) to generate
    some (fictitious) terrain maps I'll need to reproduce, and never
    considered until now that my randomization might be built on
    shaky ground.  Thanks for any help you can give,

        Chris



- -------------------------

From: [e-mail] (David Fry)
Subject:  Random Numbers (Toolbox Built-in)
Date: 2 Mar 92 13:00:14 GMT
Organization: Harvard Math Department


Random() is based on the following algorithm.  The only
difference is that this code uses all 32-bits for a random
number generator with 2^31-1 period, but Random() returns the
low two bytes for a 16-bit number.  You can avoid this by
calling Random() but then using the value in randSeed as your
random number.

Or if you're afraid of the algorithm changing in the future
(which I think is quite likely), use the following code.
For now it will give identical numbers.  See the article
mentioned in the comments below for reasons why this is a good
algorithm.

David Fry                               [e-mail]
Department of Mathematics               [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138

static    long    acm_randseed;

#define        ACM_MAX        2147483647

set_acm_seed(seed)
long    seed;
/*
*    Set the seed for the minimal standard random number generator.
*/
{
    if ( seed == 0 )
        seed = 1;
    if ( seed < 0 )
        seed = -seed;
    acm_randseed = seed;
}


long acm_random()
/*
*    This implements the "minimal standard random number generator"
*    as proposed by Park and Miller in CACM October, 1988.
*    It has a period of 2147483647.
*/
{
    long    lo, hi, test;

    hi = acm_randseed / 127773;
    lo = acm_randseed % 127773;
    test = 16807 * lo - 2836 * hi;
    if ( test > 0 )
        acm_randseed = test;
    else
        acm_randseed = test + ACM_MAX;
    return(acm_randseed);
}



- -------------------------

From: [e-mail]
Date: 4 Mar 92 00:17:49 EST
Organization: Wright State University

In article <[e-mail]>, [e-mail] (David Fry) writes:
> Random() is based on the following algorithm.
[exemplary C code deleted]

And now for something virtually identical:

unit ACMRandom;

interface

  procedure SetACMSeed (seed: LongInt);
  function ACMRandom: LongInt;

implementation

  var
    acmRandSeed: LongInt; {static variable}

  procedure SetACMSeed (seed: LongInt);
  begin
    if seed = 0 then seed := 1;
    if seed < 0 then seed := -seed;
    acmRandSeed := seed;
  end;

  function ACMRandom: LongInt;
  {"minimal standard random number generator" proposed by}
  {Parker & Miller in CACM, 1988; it has period (2^31)-1}
    var
      lo, hi, test: LongInt;
  begin
    hi := acmRandSeed div 127773;
    lo := acmRandSeed mod 127773;
    test := 16807 * lo - 2836 * hi;
    if test > 0 then acmRandSeed := test
    else acmRandSeed := test + maxLongInt;
    ACMRandom := acmRandSeed;
  end;

end.

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o


---------------------------

End of C.S.M.P. Digest
**********************